[LWDM] chore(aggregated-assets): move domain layer behind shims (LIVE-35226) - #20345

You're right — fixed in 22b1c04.

domain/entity/README.md is explicit: "Use zod for schema definition", with schema.ts and schema.test.ts listed as required, and "The schema is always required — it is the canonical data model and the primary reason the package exists." Shipping plain interfaces diverged from that.

Now follows the domain/entity/market-sentiment layout: schema.ts holds the Zod schema, types.ts infers the type via z.infer, schema.test.ts covers validation, and the barrel re-exports both.

Worth noting why this was safe to do inside a behaviour-neutral relocation, since my initial reasoning for deferring it was wrong. I had assumed adopting Zod meant adopting branded types, which would force a .parse() at the boundary and break consumers building these shapes from raw JSON. But a plain z.object() without .brand() infers a structurally identical type — so the schema can exist and be exported without anything being obliged to parse yet. Confirmed: libs/ledger-live-common still typechecks with 0 errors and the characterization tests pass unmodified (21 suites, 245 tests).

Applying .parse() at the api boundary remains LIVE-35232, which is where the drop-invalid-item semantics get decided.

Two loosenesses are deliberate and now documented and tested rather than tightened:

• InterestRate.type stays z.string() rather than the ApyType enum. DADA genuinely sends kinds outside "NRR" | "APY" | "APR" and useInterestRatesByCurrencies drops them — behaviour pinned in test(dada-client): characterize the untested surface (LIVE-35224) #20276. Narrowing here would claim a guarantee the wire doesn't give.
• fetchAt stays z.string() rather than DateTimeIsoSchema. I checked: it has zero production reads — every occurrence is a mock, fixture or Storybook story. Validating a field nobody consumes could only discard otherwise-good rates.

You're right — fixed in 22b1c04.

domain/entity/README.md is explicit: "Use zod for schema definition", with schema.ts and schema.test.ts listed as required, and "The schema is always required — it is the canonical data model and the primary reason the package exists." Shipping plain interfaces diverged from that.

Now follows the domain/entity/market-sentiment layout: schema.ts holds the Zod schema, types.ts infers the type via z.infer, schema.test.ts covers validation, and the barrel re-exports both.

Worth noting why this was safe to do inside a behaviour-neutral relocation, since my initial reasoning for deferring it was wrong. I had assumed adopting Zod meant adopting branded types, which would force a .parse() at the boundary and break consumers building these shapes from raw JSON. But a plain z.object() without .brand() infers a structurally identical type — so the schema can exist and be exported without anything being obliged to parse yet. Confirmed: libs/ledger-live-common still typechecks with 0 errors and the characterization tests pass unmodified (21 suites, 245 tests).

Applying .parse() at the api boundary remains LIVE-35232, which is where the drop-invalid-item semantics get decided.

Two loosenesses are deliberate and now documented and tested rather than tightened:

• InterestRate.type stays z.string() rather than the ApyType enum. DADA genuinely sends kinds outside "NRR" | "APY" | "APR" and useInterestRatesByCurrencies drops them — behaviour pinned in test(dada-client): characterize the untested surface (LIVE-35224) #20276. Narrowing here would claim a guarantee the wire doesn't give.
• fetchAt stays z.string() rather than DateTimeIsoSchema. I checked: it has zero production reads — every occurrence is a mock, fixture or Storybook story. Validating a field nobody consumes could only discard otherwise-good rates.

Fixed in 22b1c04 — the lockfile diff is now 48 insertions, 0 deletions, containing only the three new workspace importers.

You were right to keep pushing on this. I'd previously concluded the churn was unavoidable pnpm re-resolution triggered by the workspace set changing, and said so on an earlier PR. That was wrong. I tested it properly this time: reverting the two peer-range rewrites by hand and then running pnpm install --frozen-lockfile passes, which proves they were cosmetic rather than required.

The two reverted:

• any-observable@0.3.0: rxjs: ^5.5.10 (pnpm had rewritten it to '*')
• @storybook/addon-react-native-web@0.0.29: webpack: ^5.89.0 (rewritten to '*')

Neither package is touched by this PR, and --frozen-lockfile is what CI enforces, so keeping develop's values is both correct and reviewable.

For the record on the other half of your note: packageManager pins pnpm@10.24.0 and that is the version used, so the rewrites weren't a version mismatch — pnpm just normalises those ranges opportunistically whenever it rewrites the file.

Fixed in 22b1c04 — the lockfile diff is now 48 insertions, 0 deletions, containing only the three new workspace importers.

You were right to keep pushing on this. I'd previously concluded the churn was unavoidable pnpm re-resolution triggered by the workspace set changing, and said so on an earlier PR. That was wrong. I tested it properly this time: reverting the two peer-range rewrites by hand and then running pnpm install --frozen-lockfile passes, which proves they were cosmetic rather than required.

The two reverted:

• any-observable@0.3.0: rxjs: ^5.5.10 (pnpm had rewritten it to '*')
• @storybook/addon-react-native-web@0.0.29: webpack: ^5.89.0 (rewritten to '*')

Neither package is touched by this PR, and --frozen-lockfile is what CI enforces, so keeping develop's values is both correct and reviewable.

For the record on the other half of your note: packageManager pins pnpm@10.24.0 and that is the version used, so the rewrites weren't a version mismatch — pnpm just normalises those ranges opportunistically whenever it rewrites the file.

I don't know the type but is it compatible with DatetimeIso from @shared/schema-primitive package?

Done

Correction on my "Done" above — I reverted it in 878ad8f.

DateTimeIsoSchema is the right type (DADA sends RFC 3339, and all four timestamp shapes it produces pass the schema, 6-digit fractional seconds included). The problem was downstream: branding fetchAt broke tsc in three characterization fixtures, which had to be rebuilt through InterestRateSchema.parse(...) to compile.

Those fixtures are the safety net for the whole epic and the deal is that they pass unmodified — spending that on a nice-to-have inside a move-only PR is a bad trade, so it goes to LIVE-35232, which brands assetsIds and already expects to touch consumers.

Worth recording that the reason it looked cheap at first is that CI typechecks live-common with -p src/tsconfig.json --customConditions node, and the root config I checked first reported zero errors.

I don't know the constraint but can't it be constrained to currency ids branded types or is it completly different types?

Done; I used an union of both brands rather than CryptoCurrencyIdSchema

Same story as the fetchAt thread — reverted in 878ad8f, moved to LIVE-35232.

To actually answer the question though, since it changes what we implement there: it is not CryptoCurrencyIdSchema. DADA keys interestRates by both crypto ids (ethereum) and token ids (ethereum/erc20/usd_tether), so it needs z.union([CryptoCurrencyIdSchema, TokenCurrencyIdSchema]). That is the same union assetsIds needs on its value side, so the two are one piece of work — another reason to do them together rather than half here.

Keys can't be related to currency ids branded types too or different ids?

Will do it in this task LIVE-35232

use injectEndpoints. Empty api should be registered on @shared/api-services

I've a dedicated Jira task for it: LIVE-35301
As the task here is just to move things

Correcting myself here — this is done, not deferred. I pointed at LIVE-35301 before checking, and @shared/api-services already existed (its README even names this migration). Shipped in d4f207e.

shared/api-services/src/services/dada/ now holds the endpoint-less base with the frozen reducerPath, and domain/api/aggregated-assets does dadaApi.enhanceEndpoints({ addTagTypes }).injectEndpoints(...). One reducer, one middleware, one cache slice — which createCurrencyDataSelector depends on, since it hand-scans state.assetsDataApi.queries by string.

Two things genuinely left, both needing consumer changes so out of a move-only PR:

• the base URL is still resolved in domain/api via getEnv("DADA_API_*"), where it should reach the service as extraArgument
• the apps still register the use-case api rather than dadaApi

LIVE-35301 is now scoped to splitting the single injectEndpoints call into three per-use-case modules, which is the part that actually needed its own revert.

This is a bit messy. It should be more something like export * from "file" all the rest you don't want to expose should go on internals files or dir.

Fixed

Files under internals should not be exposed

Done

Could go on internals and could be tested there

Done

Could go to internals too

Done

Maybe better to move them into an accessors.ts file

Done

If just for package test move it to a fixtures dir